Resource ReSerVation Protocol (RSVP) is a resource reservation setup protocol currently being standardized by the Internet Engineering Task Force (IETF). RSVP provides receiver-initiated setup of resource reservations for multicast and unicast data flows.
Referring to FIG. 1, a basic broadband cable data distribution system 10 is shown as having a cable head end/distribution hub 12 connected to one or more audio/video and data sources 14, such as a satellite receiver. The cable head end 12 distributes the received signals to a plurality of end user computers 16 using at least one cable modem termination service (CMTS) 18 and a coaxial or hybrid optical/coaxial cable 20. The CMTS 18 provides dynamic allocation or reservation of network bandwidth/resources to selectively control access and quality of service to the network for end users 16. The end users are typically connected to the network via a cable modem (CM) 22. With respect to downstream bandwidth, end users share the bandwidth in accordance with a time sharing allocation protocol, such as an Ethernet contention protocol, or a specially granted service I.D. (SID) generated by the CMTS in accordance with a predetermined time allocation map.
Generally, the basic RSVP protocol assumes the implementation of two modules on each RSVP-capable node to forward data packets: the "packet classifier" and the "packet scheduler." The packet classifier determines the route and quality of service (QOS) class for each packet, and sends the packet to the packet scheduler. The RSVP packet classifier uses a "filter spec" which matches a particular source internet protocol (IP) address and source port to classify and restrict traffic that consumes reservation resources/bandwidth. The packet scheduler makes packet forwarding decisions such as queuing decisions to achieve a predetermined QOS on the interface. The RSVP packet scheduler uses a "flow spec" which identifies token packet parameters, peak data rate, etc. to identify the desired QOS.
In the context of RSVP for upstream traffic, it is desirable for the CM to perform the "packet classifier" function, but the CMTS to perform most of the "packet scheduler" function. While CMTS have utilized different levels of SIDs relating to different levels of quality of services, such arrangements have been fixed and inefficient in that there was no ability to control how much of the available resources a user would be able to reserve. Thus, a need exists for an arrangement which can adequately support a split of function between the CMTS and the CM to dynamically allow reservation of available upstream bandwidth and corresponding improvement in system efficiency.